1 Hintergrundinfos

1.1 Zusammenarbeit mit anderen Programmen

‘RSYS’ wurde unter Berⁿcksichtigung aller mir bekannten Richtlinien der Programmierung unter AmigaOS 2.0 geschrieben. Alle kritischen Routinen wurden bis zu dreimal abgesichert. Das blΣht zwar etwas den Code, gewΣhrleistet aber die LauffΣhigkeit auch unter Betriebssystemen >= 2.04.

Besonderer Wert wurde auf die Vermeidung von Speicherfehlern und ‘Enforcer’-Hits gelegt. Bei einem auftretenden Speicherfehler wird in den meisten FΣllen das Programm unter Angabe von Quelldatei- und Funktionsname, sowie der Zeilennummer im Quelltext abgebrochen und beendet.

‘RSYS’ ist darauf ausgelegt, mit allen Programmen so gut wie m÷glich zusammenzuarbeiten. Das schlie▀t jedoch die Programme aus, die von Haus aus Hacks sind, die sich nicht an die Programmierrichtlinien unter AmigaOS halten. Weiterhin hat ‘RSYS’ keinerlei Problem mit systemkonformen Patches, wie z.B. ‘MagicMenu’ von Martin Kornd÷rfer, oder ‘MFR’ von Stefan Stuntz.

Viele Leute haben mich per EMAIL angeschrieben, da▀ ich doch bitte OS 3.0-Features verwenden soll. ‘RSYS’ soll eigentlich unter allen Systemen >2.0 laufen, weswegen ich spezielle Features von 3.0 absichtlich vermieden habe. Ausnahmen bilden jedoch einige verwendete Tags, wie z.B. die GTM_NewLookMenus, das die Standard-3.0-Menⁿfarben einstellt. Diese werden von OS 2.x-System ignoriert, womit also dem Einbau nichts im Wege stand.

Ein weiteres Feature von OS 3.0 ist die Routine GT_GetGadgetAttrsA der ‘gadtools.library’. Damit wird eine vollstΣndige Steuerung der ListView-Gadgets ⁿber Pfeiltasten erm÷glicht. Diese ist jedoch unter 2.x noch nicht implementiert, soda▀ auch dieses Feature in ‘RSYS’ aus Grⁿnden der KompatibilitΣt nichts zu suchen hat.

1.2 Systemlisten und Schutzprotokolle

Intuition-Objekte werden beim Auslesen der Daten mit dem Protokoll LockIBase() / UnlockIBase() geschⁿtzt. Damit werden die jeweiligen Listen vor der VerΣnderung durch Intuition-Routinen wΣhrend des Auslesens ausreichend geschⁿtzt. Bei der VerΣnderung der Objekte durch ‘RSYS’ ist selten ein Schutzprotokoll erforderlich, da die Routinen von Intuition dieses meistens selbst erledigen.

Alle Exec-Objekte, wie Tasks, Ports, Libraries, etc., werden wΣhrend des Auslesens durch ein Forbid()/Permit(), im Falle von Tasks, sogar durch ein Disable()/Enable() vor VerΣnderung durch Systemroutinen geschⁿtzt. Im Falle der Tasks ist zum Auslesen der Taskzeiger das Protokoll Disable()/Enable() zu verwenden, zum Auslesen der Taskstruktur reicht jedoch ein Forbid()/Permit().

Disable()/Enable() sollte deswegen verwendet werden, da die Systemliste in der ExecBase durch den interruptgesteuerten Task-Scheduler laufend in ihrer Anordnung geΣndert wird (man denke nur an die Aktivierung eines Tasks, also die Umsetzung des entsprechenden Taskknotenzeigers aus der Wait-Liste in die Ready-Liste und dann in den Running-Zustand [ExecBase->ThisTask-Eintrag]).

Die Task-Struktur selber kann jedoch nur von einem Task oder Proze▀ aus verΣndert werden. Daher reicht zum Auslesen der Taskstruktur das Protokoll Forbid()/Permit() aus. Daraus ergibt sich also folgendes Schema:

   Reservieren der eigenen Struktur-Speicherbereiche

   Forbid();

      Disable();
      Auslesen und Merken der Tasknodes
      Enable();

      Auslesen der Taskstrukturen in eigene Strukturen (ohne
      Verwendung von DOS-Routinen, also KEIN FGets(), Open() etc.)

   Permit();

   Auswerten der eigenen Strukturen
   Freigeben der eigenen Struktur-Speicherbereiche

Fⁿr die Implementation dieser Routinen k÷nnt Ihr den dokumentierten Quelltext einsehen.

Unter diesen Vorsichtsma▀nahmen sollte es keine Probleme im Zusammenspiel mit anderen Programmen geben, bis auf eine EinschrΣnkung: ‘RSYS’ kann nicht mit Programmen zusammenarbeiten, die nicht systemkonform programmiert wurden. Beispiele dafⁿr sind Programme, die beispielsweise den Namen eines ÷ffentlichen Ports nicht korrekt initialisieren. So kommt es beispielsweise vor, da▀ ein Programm zwar einen Zeiger auf einen Portnamen ungleich Null hat, diesen Zeiger aber uninitialisiert lΣ▀t und dieser dann folglich irgendwohin zeigt. Die Folge ist im harmlosesten Fall ein ‘Enforcer’-Hit des Typs READ-BYTE (beim Auslesen des vermeintlichen Strings), im extremsten Fall ein Guru!

Ich habe das Problem jetzt so gel÷st, da▀ ich bei den auszulesenen Node-Namen das Typen-Flag untersuche. Steht dort der Eintrag NT_UNKNOWN oder nicht das erwartete Flag, lese ich den String einfach nicht aus, sondern trage in das ListView

   <wrong type:0>

ein. Hierbei steht die 0 fⁿr den ermittelten Knotentypen. Die m÷glichen Knotentypen sind:

 Wert       Typ
------------------------------------------------------
   0        Unbekannter Node-Typ
   1        Task
   2        Interrupt
   3        Device
   4        Message Port
   5        Message
   6        freie Message
   7        Message wurde beantwortet
   8        Resource
   9        Library
  10        Memory-Node
  11        Softinterrupt
  12        Font
  13        Proze▀
  14        Semaphor
  15        Signalsemaphor
  16        Boo-Node
  17        Kick-Memory-Node
  18        Graphics-Node (Monitor-Node z.B.)
  19        Death Message (eine tote Nachricht)
 254        Benutzerdefinierter Node
 255        Erweiterung (auch benutzerdefiniert)

Manche Systemutilities (z.B. ARTM) achten darauf nicht und produzieren ‘Enforcer’-Hits en mas. Diese Fehler lassen sich auch nicht vermeiden. Der Aufwand dafⁿr wΣre einfach zu gro▀, da man ja praktisch Teile des Programms ‘Enforcer’ in das eigene Programm implementieren mⁿ▀te. Solange man nicht davon ausgehen kann, da▀ JEDER Programmierer systemkonform programmiert, wird es diese Lⁿcke auch weiterhin geben.

Ein weiterer typischer Fehler ist die Verwendung der Compiler-Funktion strcpy() auf Quellstrings vorher unbekannter LΣnge. Viele Programmierer verwenden diese Routine, um schneller Strings zu kopieren. Dabei wird nicht beachtet, da▀ man eventuell gar nicht soviel Speicherplatz reserviert hat, um den Quellstring aufzunehmen. Ein signifikantes Beispiel dafⁿr ist das o.g. Port-Namen-Problem. Ist der String uninitialisiert und nicht mit ASCII 0 terminiert, kopiert strcpy() einen solchen Portnamen bis in alle Ewigkeit, bis zum Ende des Speichers, bis zur nΣchsten Einsprungadresse eines anderen Tasks oder bis zur nΣchsten Reise von Indian tours :-) Manche Programmierer sagen sich dann, ⁿberprⁿfen wir doch einfach mit strlen() den Quellstring. Nun, da strlen() auch solange zΣhlt, bis ASCII 0 erkannt wurde, ist diese Methode auch fⁿr eine Auslandsreise nach Indien durchaus geeignet.

Das einfachste und probateste Mittel in diesem Fall, ist die Compiler-Funktion strncpy(). Damit kann man einfach festlegen, wieviel Zeichen denn nun kopiert werden sollen. Das einzige, was jetzt noch st÷rt, ist der READ-BYTE-Hit den man bekommt, wenn man merkwⁿrdige Adressen an strncpy() ⁿbergibt.

Ein weitere Fehlerquelle ist die Verwendung von printf() in allen seinen Erscheinungsformen (sprintf(), vsprintf() etc.) im Zusammenhang mit Systemlisten. Da die printf()-Routinen auch auf DOS-Routinen zugreifen, sind sie zum zⁿgigen Kopieren von mehreren SystemeintrΣgen ungeeignet. Die Routine RawDoFmt() der Exec-Library ist jedoch sicher. Mit ihr kann man sich selbst ein sprintf() zusammenbauen, was ich auch getan habe. Normalerweise befindet sich aber diese Routine in der ‘amiga.lib’.

Sicher ist weiterhin die Verwendung der str...()-Routinen zwischen Schutzprotokollen, da diese nur Speicherbereiche kopieren oder verschieben. M÷chte man es trotzdem noch schneller haben, gibt es noch die Funktionen CopyMem() und CopyMemQuick(). Bei letzterer ist zu beachten, da▀ die Daten auf longwords ausgerichtet sein mⁿssen. Beide Routinen geh÷ren zur ‘exec.library’, k÷nnen also bei Systemlistenuntersuchungen verwendet werden.

About This Document

This document was generated on January 28, 2023 using texi2html 5.0.

The buttons in the navigation panels have the following meaning:

where the Example assumes that the current position is at Subsubsection One-Two-Three of a document of the following structure:

• 1. Section One
  • 1.1 Subsection One-One
    • ...
  • 1.2 Subsection One-Two
    • 1.2.1 Subsubsection One-Two-One
    • 1.2.2 Subsubsection One-Two-Two
    • 1.2.3 Subsubsection One-Two-Three     <== Current Position
    • 1.2.4 Subsubsection One-Two-Four
  • 1.3 Subsection One-Three
    • ...
  • 1.4 Subsection One-Four

This document was generated on January 28, 2023 using texi2html 5.0.